Multicast for Small Conferences

This paper describes a concept to support scalable multicast communications for small audio / video conferencing groups in the Internet. The solution presented in this paper is based on extensions of IPv6 and the session description protocol (SDP). A goal of the concept called Multicast for Small Conferences (MSC) is the smooth deployment in the Internet. 1. Scalable Multicast Techniques Telecommunication companies are beginning to replace telephone backbone connections by IP networks. IP multicast as the natural IP technology for audio/telephone conferences does not scale for large numbers of small groups [1], since multicast routing entries within routers can not be aggregated such as unicast routing entries. While leading unicast address prefixes can be used for routing entry aggregation, multicast address selection can be arbitrary so that multicast addresses with equal similar prefixes do not need to have any relation to each other such as common multicast delivery trees. The Multicast Address Allocation Architecture (Malloc) addresses this problem in the context of allocation mechanims for unique multicast addresses [9]. The scalability problem gets even worse since multicast routing may also depend on source addresses. This means that a backbone router needs a multicast routing entry for each global multicast address (or each source / multicast address pair) even if this multicast group consists of a few members only. Several proposals have arised recently addressing this scalability problem. The Small Group Multicast (SGM) [1] concept introduces a new protocol layer between IP and the transport layer. The corresponding SGM header has been specified as a protocol header following the IPv4 header [2] and consists of a list of the IP addresses of all group members. When sending a multicast packet, the unicast addresses of all receivers are put into the IP destination address and the SGM header respectively. A SGM router scans the complete address list of an arrived packet and determines the outgoing interfaces for each of the addresses. A new packet copy is generated for each outgoing interface. Each address list of a packet then only contains the addresses that can be reached via that interface. While SGM solves the scalability problem, several problems remain. First, SGM introduces a new protocol and a new protocol ID in the IP header. Second, for a smooth deployment, SGM tunnels have to be set up among SGM capable routers. Finally, SGM does not rely on established multicast mechanisms such as IGMP making it difficult to allow native multicast receivers to join a multicast group. Although gateways that translate IP multicast packets into SGM packets can be deployed, the problem remains that those gateways have to synchronize themselves in order make sure that the same IP multicast address is being used for the same set of receivers or multicast group respectively. Although the avoidance of class D IPv4 addresses has many benefits such as avoidance of multicast address allocation [9] existing IP multicast applications should also be supported. A similar approach as SGM called Somecast is based on IPv4 options [7]. Like the proposal described in this paper, the Multiple Destination Option on IPv6 (MDO6) is based on SGM and IPv6. MDO6 also proposes to define a new IPv6 routing header or a new destination option. MDO6 does not support native IPv6 multicast, but proposes an ordered list of receivers in the new extension headers in order to make router processing more efficient [10]. MDO6 proposes new ICMP messages for exploring multicast delivery trees. 3. Telephone Conferencing over the Internet The growing use of Internet technology in telephone backbones yields additional advantages for audio conferencing. Traditional audio conferencing in telephone networks is quite complex to set up and very inefficient regarding bandwidth usage since audio traffic is always sent to a MCU that finally distributes it via point-to-point connections to the various receivers. Therefore, it seems to be very promising to use IP multicast for the Internet interconnection of gateways that provide access to legacy telephone users or even of Internet telephony terminals directly. To support a conference, the IP terminals and the gateways serving the conferencing participants have to join a common multicast group and may exchange the traffic via IP multicast mechanisms. This avoids the multiple transport of the same traffic over the backbone network as it is the case in traditional telephone conferences based on MCUs. Those gateways should also support nonmulticast capable IP terminals / phones. Figure 1 shows our target scenario. Gateways are interconnected via the Internet and communicate via IP multicast. The gateways serve non-multicast capable end systems such as unicast IP phones or legacy phones. In such a scenario, typically a relatively small number of participants are involved. Therefore, the multicast group consisting of both IP multicast receivers (IP telephony terminals) and gateways is relatively small, typically less than 10 group members. For such a small multicast group, it makes hardly sense to burden backbone Internet routers and force them to store a multicast routing entry for this group or even for each (source, multicast address) pair. In particular the SGM concept seems to be very useful for supporting the target scenario, but the disadvantages mentioned above must be overcome. To support a scenario as depicted in Figure 1, we propose to use the MSC mechanism for interconnecting gateways and IP terminals. Since the gateways and IP terminals must then be MSC capable, we call these MSC gateways and MSC terminals, hereafter. The MSC gateways have also the task to serve non-MSC capable IP terminals such as IPv4 or IPv6 only terminals that do not support MSC. While for IPv4 terminals IPv6/IPv4 packet translation has to be performed, for IPv6 terminals only extension headers and options are inserted, modified or deleted by the MSC gateways. Fig. 1: Multicast conferencing scenario 4. Multicast for Small Conferences We propose to use MSC concept for multicast packet delivery in the Internet backbone while current available intra-domain multicast routing mechanisms shall be used for regional or access networks. This approach avoids multicast routing overhead in backbone routers. Those have only to maintain unicast routing tables but should ideally be able to process the MSC protocol information included as IPv6 extension headers or options. 4.1 IPv6 Extensions for MSC In contrast to define a new protocol such as SGM we propose to realize the MSC concept based on IPv6, in particular on the IPv6 routing header. The IPv6 routing header (type 0) (Figure 2) has been proposed to be used for a kind of source routing [3]. However, multicast addresses must not appear in a routing header of type 0, or in the IPv6 destination address field of a packet carrying a routing header of type 0. To overcome this limitation we propose two solutions. The first (shortterm) solution is compatible with all current IPv6 routers, while the second solution is recommended for long-term usage. In both solutions the routing header carries a list of unicast addresses of all multicast group members, that means the MSC gateways and MSC terminals as shown in Figure 1. In addition, the multicast address is also carried in the IPv6 packet. While in the first solution the multicast address is carried in a newly defined IPv6 destination option, in the second solution it is carried at the end of the newly defined type 1 IPv6 routing header. Fig. 2: IPv6 routing header Solution I. The destination options header is used to carry optional information that need to be examined only by a packet’s destination node(s). The destination options header is identified by a next header value of 60 in the preceding header, and has the format shown in Figure 3. The options field (Figure 4) is of variable length, but must be an integer multiple of 8 octets long. It contains one or more TLV-encoded (TLV: type, length, value) options. In our case, the option data should contain an IPv6 multicast address, so the option length is 16 bytes. The option type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the option type. In our case these two bits should be set to 00 so that an IPv6 router just skips over this option and continues processing the header. The third-highest-order bit of the option type specifies whether or not the option data of that option can change en-route to the packet’s final destination. When an authentication header is present in the packet, for any option whose data may change en-route, its entire Option Data field must be treated as zero-valued octets when computing or verifying the packet’s authenticating value: the value of 1 should be set since the option might change en-route, in particular if the option is inserted or discarded. Fig. 3 : IPv6 destination options format